Sunday, 13 November 2022

Building products in services companies

I’ve worked in a couple of organisations that were coming from a background of a services based delivery model and trying to move to being product companies. The motivation for this kind of move is clear when revenue multiple valuations are so much higher in the product space. What I’ve seen from these experiences is that the route to success is far more challenging than people realise. Here I’ll dig into some of the biggest common challenges I’ve encountered that can hold these companies back.

With Products there’s no backup plan

Building products is hard. Don’t get me wrong I have huge respect for anyone that work closely with customers in a professional services context and keep them happy. Its just that building products is a much more proactive endeavour than delivering consultancy or bespoke projects which have a higher level of reactivity. It takes a lot of discovery effort and discipline to create a product that meets the needs of multiple customers in a consistent way with a common feature set.

When creating technology in support of a services-led offer you are operating with more of a safety net of filling the gaps in product functionality with people. This could be by taking on the project administration yourself or running some reports or communications outside the standard product workflow. When creating products a lot more time and effort needs to go into providing a coherent and complete experience with each increment - as throwing people at the problem is not an option.

A different basis of success

There’s an interesting dichotomy in some companies between what they think is the basis of their success and why the customers use them. Many services companies are founded based on a deep domain expertise - usually in one or more founders. These will inevitably feed some standard frameworks or company collateral that adds value through credibility. It will ultimately fall to the project teams providing that service to ensure a valuable delivery to the customer through custom content creation and design alongside high-touch delivery.

While it may not be political to say it - there’s probably a much higher reliance simply on the quality and flexibility of the service and the talents of those in sales building deep customer relationships than any 'secret sauce' baked into their approach or technology. The market knowledge of individuals negotiating the sales and delivering the service, their competence and their responsiveness to customer needs will have been a massive driver of success historically in a successful consultancy or agency.

Overestimation of IP

A natural consequence of the above is that service companies tend to place a much higher valuation on the IP within the business than is realistic. This presents a challenge when these companies look to capture their approach in scalable products. Once you remove the high value-add that the service provides, there's likely to be a much thinner basis of value to encapsulate into a product experience than they may want to admit to themselves. There's a high chance that the competitive landscape suddenly looks very different when viewing things through a product lens, with more ‘out of the box’ providers suddenly looking a lot further ahead on the journey a company plans to go on than they are given the competitor's higher relative investment into technology, user experience and product-led growth.

Another area where IP can be over-valued is in having large quantities of data collected. Unless data is explicitly collected with the relevant categorisations and ‘levers’ to connect it to meaningful business decisions then it will be difficult to monetise. To grow a valuable corpus of data requires forethought and planning, it's unlikely that a services company will create themselves a data goldmine unintentionally.

A company I worked with a few years ago had the good sense not to assume there was value in their data and engaged an expert data scientist to analyse the huge amounts of management data they had gathered - the results were predictably disappointing and they found no monetisable value at all. If you want value in your data you have to build it in from the start.

Project based technology

Until the explicit decision to create tech products is made, most software in services-led organisations will be spawned as part of a customer project - and then leveraged and built on to deliver to other customers.

The result is technology that has been created ‘incrementally’ rather than ‘intentionally’ - and without the architectural rigour that comes with investing in a product that is designed to serve multiple customers with common features from day one. By the time the needs of the fifth or sixth customer use case is supported a rapidly developed tool can become a heavy burden for the engineering team to carry. Even when the intention is there to build more cross-cutting products the temptation to sell these too early before the product is ready can result in making massive compromises as extensibility and scalability are dispensed with to meet a customer project deadline.

Not wanting to say no

A vital element of a product relationship is an ability to say no to customer requests if they don't fit with the direction you want the product to go in. This is a much easier discussion with the right basis of the relationship from the outset. It's a bitter pill for a customer to swallow when they hear no for the first time after years of getting their every request serviced.

The same applies internally. Sales teams whose Ideal Customer Profile is ‘anyone with money’ and who expect to get new features added from one customer project to the next to hit their revenue targets may not respond too well to shifting to a ‘Now, Next, Later’ roadmap.

Creating products should implicitly be an agile endeavour to focus on and deliver the highest value incrementally - however there is a level of proactivity involved in exploring the needs of many customers and ensuring good solutions to common problems or valuable opportunities. A culture more used to reacting to customer requests and getting them delivered may find this hard to grasp.

Too broad a focus

Not saying no doesn’t just apply to customer requests - there’s also a need to say no to opportunities or even market sectors if the product portfolio isn’t best set up to serve them. Good product companies will target one market segments, drive discovery and development towards serving their needs and grow the range of segments supported over time through intentional development of their product portfolio.

When a company is chasing revenue rather than growing out a product vision the result will be a weak set of offerings across a wide range of segments, typically prompted by targeting one or two opportunities in those areas and spinning up tools to serve them that rely heavily on the previously mentioned safety net of being able to fill the gaps in capability with people.

A big challenge

The challenge of shifting a technology-backed but service-led company into a product one are significant and one that as a product person I suggest approaching with caution. It’s no coincidence that my writing has taken a pause over the last year while I’ve been taking on such a challenge - I don't find a lot of inspiration in the political conflicts that are involved. Even when I've had similar roles in the past that I enjoyed more - they still involved significant battles with account teams over responsibility and prioritisation decisions as we strived to create core technology platforms under the banner of major customer projects.

If you relish the challenge of shifting a culture and overcoming resistance to taking a different approach then this kind of role may be for you. For me personally the political challenges and conflict negotiation involved are simply not problems that I relish solving.

References

Whatsapp Button works on Mobile Device only

Start typing and press Enter to search